Red Hat System Administration II 8.2
Задачи
После завершения этого раздела вы сможете планировать выполнение команд по повторяющемуся расписанию с помощью системного файла и каталогов crontab.
Повторяющиеся системные задания
Системным администраторам часто приходится выполнять повторяющиеся задания. Рекомендуется запускать такие задания из системных учетных записей, а не из пользовательских. То есть вместо команды crontab используйте системные файлы crontab для планирования заданий. Записи заданий в системных файлах crontab аналогичны записям в пользовательском файле crontab. Единственное исключение — в системных crontab перед полем команды есть дополнительное поле, в котором указан пользователь, от имени которого должна выполняться команда.
В комментариях в файле /etc/crontab
есть полезная синтаксическая диаграмма.
# For details see man 4 crontabs # Example of job definition: # .---------------- minute (0 - 59) # | .------------- hour (0 - 23) # | | .---------- day of month (1 - 31) # | | | .------- month (1 - 12) OR jan,feb,mar,apr ... # | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue ... # | | | | | # * * * * * user-name command to be executed
Повторяющиеся системные задания определяются в двух местах: в файле /etc/crontab
и файлах каталога /etc/cron.d/
. Вы всегда должны создавать свои собственные файлы crontab в каталоге /etc/cron.d
для планирования повторяющихся системных заданий. Поместите пользовательский файл crontab в /etc/cron.d
, чтобы защитить его от перезаписи в случае обновления пакета у поставщика /etc/crontab
, в результате которого содержимое /etc/crontab
может быть перезаписано. Пакеты, которым требуются повторяющиеся системные задания, размещают свои файлы crontab в файле /etc/cron.d/
, содержащем записи заданий. Администраторы также используют это расположение для группирования связанных заданий в одном файле.
В системе crontab также есть репозитории для сценариев, которые должны запускаться каждый час, день, неделю и месяц. Эти репозитории представляют собой каталоги /etc/cron.hourly/
, /etc/cron.daily/
, /etc/cron.weekly/
и /etc/cron.monthly/
. Эти каталоги содержат исполняемые сценарии командной оболочки, а не файлы crontab.
Важно
Сценарии, помещаемые в эти каталоги, должны быть исполняемыми. Если сценарий не является исполняемым, он не будет выполнен. Чтобы сделать сценарий исполняемым, используйте команду chmod +x script_name
.
Команда run-parts, вызываемая из файла /etc/cron.d/0hourly
, запускает сценарии /etc/cron.hourly/*
. Команда run-parts также выполняет ежедневные, еженедельные и ежемесячные задания, но она вызывается из другого файла конфигурации ― /etc/anacrontab
.
Примечание
В прошлом для обработки файла /etc/anacrontab
использовалась отдельная служба anacron
, но в Red Hat Enterprise Linux 7 и более поздних версиях этот файл обрабатывает стандартная служба crond
.
Назначение файла /etc/anacrontab
— обеспечить выполнение важных заданий, чтобы они случайно не были пропущены из-за выключения или гибернации системы. Например, если ежедневное системное задание не было выполнено из-за перезагрузки системы, оно будет выполнено при возобновлении работы системы. Однако возможна задержка запуска задания в несколько минут в зависимости от значения параметра Delay in minutes
, указанного для задания в файле /etc/anacrontab
.
В /var/spool/anacron/
есть файлы для каждого из ежедневных, еженедельных и ежемесячных заданий. По ним можно определить, было ли выполнено конкретное задание. Когда демон crond
запускает задание из /etc/anacrontab
, он обновляет метки времени этих файлов. Та же метка используется для определения времени последнего выполнения задания. Синтаксис файла /etc/anacrontab
отличается от обычных файлов конфигурации crontab
. Каждая строка этого файла содержит четыре поля, которые описаны ниже.
Период в днях
Интервал в днях для задания, которое выполняется по повторяющемуся графику. Это поле принимает целое число или макрос в качестве значения. Например, макрос
@daily
эквивалентен целому числу1
, то есть задание выполняется ежедневно. Точно так же макрос@weekly
эквивалентен целому числу7
, то есть задание выполняется еженедельно.Задержка в минутах
Период времени до запуска задания демоном
crond
.Идентификатор задания
Уникальное имя для идентификации задания, например в log-файлах.
Команда
Команда, которую необходимо выполнить.
Файл /etc/anacrontab
также содержит объявления переменных среды с использованием синтаксиса ИМЯ=значение
. Особый интерес представляет переменная START_HOURS_RANGE
, которая указывает временной интервал выполнения заданий. Задания не запускаются вне этого диапазона. Если в какой-то день задание не будет выполнено в этот промежуток времени, следующий запуск задания состоится только на следующий день.
Таймер systemd
С появлением systemd
в Red Hat Enterprise Linux 7 стала доступна новая функция планирования заданий: юниты таймера systemd
. Юнит таймера systemd
активирует еще один юнит другого типа (например, службу), имя которого совпадает с именем юнита таймера. Юнит таймера обеспечивает активацию других юнитов по времени. Для упрощения отладки systemd
регистрирует события таймера в системные журналы.
Пример юнита таймера
Пакет sysstat предоставляет юнит таймера systemd
с именем sysstat-collect.timer
для сбора системной статистики каждые 10 минут. В следующем выводе показаны строки конфигурации файла /usr/lib/systemd/system/sysstat-collect.timer
.
...output omitted...
[Unit]
Description=Run system activity accounting tool every 10 minutes
[Timer]
OnCalendar=*:00/10
[Install]
WantedBy=sysstat.service
Параметр OnCalendar=*:00/10
указывает, что этот юнит таймера активирует соответствующий юнит (sysstat-collect.service
) каждые 10 минут. Однако можно указывать более сложные интервалы времени. Например, значение 2019-03-* 12:35,37,39:16
параметра OnCalendar
заставляет юнит таймера активировать соответствующий юнит службы в 12:35:16
, 12:37:16
и 12:39:16
каждый день в течение марта 2019 года. Вы также можете указывать относительные таймеры с помощью таких параметров, как OnUnitActiveSec
. Например, опция OnUnitActiveSec=15min
заставляет юнит таймера активировать соответствующий юнит через 15 минут после последней активации.
Важно
Не изменяйте файл конфигурации юнита в каталоге /usr/lib/systemd/system
, поскольку любое обновление пакета поставщика, влияющее на файл конфигурации, может перезаписать изменения конфигурации, внесенные вами в этот файл. Поэтому создайте в каталоге /etc/systemd/system
копию файла конфигурации юнита, который необходимо изменить, и отредактируйте эту копию, чтобы сделанные вами изменения конфигурации юнита не перезаписывались обновлениями пакета поставщика. Если в каталогах /usr/lib/systemd/system
и /etc/systemd/system
есть два файла с одинаковыми именами, systemd
обработает файл в каталоге /etc/systemd/system
.
Изменив файл конфигурации юнита таймера, выполните команду systemctl daemon-reload, чтобы убедиться, что systemd
видит изменения. Эта команда перезагружает конфигурацию диспетчера systemd
.
[root@host ~]#
systemctl daemon-reload
Перезагрузив конфигурацию диспетчера systemd
, выполните следующую команду systemctl, чтобы активировать юнит таймера.
[root@host ~]#
systemctl enable --now <
unitname
>.timer
Ссылки
Man-страницы crontab(5), anacron(8), anacrontab(5), systemd.time
(7), systemd.timer
(5) и crond
(8)